fix(context): restore skills after compaction - #9043

👋 Hi! This PR's description is missing some required sections from our PR template. Workflow runs won't be auto-approved until the description is updated.

Missing sections:

• ## Problem / Motivation
• ## Why it matters
• ## What changed

Please update your PR description to include these sections, then push or re-save the description. The workflows will be approved on the next cycle.

GPT 5.6 Review (fork) — ✅ no blocking findings

Reviewed a76f976ac01683e2d95072fda3980637fb86ea9f via the fork AI-review pipeline; updated in place on each push.

Opus 4.8 Review (fork) — ✅ no blocking findings

Reviewed a76f976ac01683e2d95072fda3980637fb86ea9f via the fork AI-review pipeline; updated in place on each push.

Design Review (Fable 5, fork) — 🟡 CONCERNS

Design-level review of a76f976ac01683e2d95072fda3980637fb86ea9f via the fork AI-review pipeline — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

Design-Verdict: CONCERNS

The identical skills-loss bug stays live on messaging: driver.py:773 sees the same "completed" event but this PR arms only the dashboard runner.

Watch

The PR's stated harm — "the next user turn can therefore no longer discover the skills available to the session" — applies equally to messaging: the driver handles EVENT_COMPACTION_STATUS (src/kiro_crew/messaging/driver.py:773) without arming, messaging serves manual /compact (commands.py:321), and its dispatch already consumes the flag (src/kiro_crew/messaging/dispatch.py:777). The spec hunk ("does not add skills reinjection to messaging surfaces or the task runner") records the gap but leaves the same user harm shipping on those surfaces, and the per-surface arming shape means each future surface must remember its own arm.
Clears when: the messaging driver's EVENT_COMPACTION_STATUS/wait_for_compaction completion paths arm the same flag (a near-identical one-liner), or a linked follow-up issue owns that surface explicitly.

[DESIGN-REVIEWED] a76f976

First Principles Review (Fable 5, fork) — 🟡 CONCERNS

Premise-level review of a76f976ac01683e2d95072fda3980637fb86ea9f via the fork AI-review pipeline — why this exists and whether the shipped surface is the smallest honest version. Updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

First-Principles-Verdict: CONCERNS

Dashboard-only arm: the same unarmed-reinjection gap stays at 17 counted compaction sites across 11 messaging surfaces and the task runner.

Not justified as shipped

• Item 1 — symptom-level: the arm lands at the dashboard's three completion points while the identical gap persists at 17 wait_for_compaction sites across 11 surfaces (slack, telegram, discord, teams, webex, wecom, weixin, whatsapp, imessage, feishu, task_executor) plus messaging/driver.py:773 — all of which consume the flag (messaging/dispatch.py:777) and none of which arm it (grep mark_needs_reinjection: only session_compaction.py:650, chat_runner.py:14073, handlers/members.py:897). The deferral is declared only in the doc hunk ("does not add skills reinjection to messaging surfaces or the task runner"), never in the description.
  Clears when: the sibling surfaces' compaction-completion points arm the flag, or a linked issue records the deferral.

What this change ships

[FIRST-PRINCIPLES-REVIEWED] a76f976

Rebased onto main 6fbb06bcd by a maintainer as part of the 2026-09-08 open-PR audit. The branch was 163 commits behind; it is now a single commit on current main.

Conflicts: none — clean rebase, diff unchanged at +38/-0 in 2 files.

Gates run locally (changed files only): black --check, isort --check-only, flake8 all clean; pytest test/test_dashboard_chat.py -n0 → 769 passed.

Please review the rebased head. Note that a maintainer push makes the maintainer the last pusher, so under this repo's last-push rule a second approver is needed before merge. Reply here if anything looks wrong.